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Per Hop Behavior Identification Codes 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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1. Introduction 


Differentiated Services [RFC 2474, RFC 2475] introduces the notion of 
Per Hop Behaviors (PHBs) that define how traffic belonging to a 
particular behavior aggregate is treated at an individual network 
node. In IP packet headers, PHBs are not indicated as such; instead 
Differentiated Services Codepoint (DSCP) values are used. There are 
only 64 possible DSCP values, but there is no such limit on the 
number of PHBs. In a given network domain, there is a locally defined 
mapping between DSCP values and PHBs. Standardized PHBs recommend a 
DSCP mapping, but network operators may choose alternative mappings. 
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In some cases it is necessary or desirable to identify a particular 
PHB in a protocol message, such as a message negotiating bandwidth 
management or path selection, especially when such messages pass 
between management domains. Examples where work is in progress 
include communication between bandwidth brokers, and MPLS support of 
diffserv. 


In certain cases, what needs to be identified is not an individual 
PHB, but a set of PHBs. One example is a set of PHBs that must follow 
the same physical path to prevent re-ordering. An instance of this 
is the set of three PHBs belonging to a single Assured Forwarding 
class, such as the PHBs AF11, AF12 and AF13 [RFC 2597]. 


This document defines a binary encoding to uniquely identify PHBs 
and/or sets of PHBs in protocol messages. This encoding MUST be used 
when such identification is required. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.1. Usage Scenarios 


Diffserv services are expected to be supported over various 
underlying technologies which we broadly refer to as "link layers" 
for the purpose of this discussion. For the transport of IP packets, 
some of these link layers make use of connections or logical 
connections where the forwarding behavior supported by each link 
layer device is a property of the connection. In particular, within 
the link layer domain, each link layer node will schedule traffic 
depending on which connection the traffic is transported in. Examples 
of such "link layers" include ATM and MPLS. 


For efficient support of diffserv over these link layers, one model 
is for different Behavior Aggregates (BAs) (or sets of Behavior 
Aggregates) to be transported over different connections so that they 
are granted different (and appropriate) forwarding behaviors inside 
the link layer cloud. When those connections are dynamically 
established for the transport of diffserv traffic, it is very useful 
to communicate at connection establishment time what forwarding 
behavior(s) is(are) to be granted to each connection by the link 
layer device so that the BAs transported experience consistent 
forwarding behavior inside the link layer cloud. This can be achieved 
by including in the connection establishment signaling messages the 
encoding of the corresponding PHB, or set of PHBs, as defined in this 
document. Details on proposed usage of PHB encodings by some MPLS 
label distribution protocols (RSVP and LDP) for support of Diff-Serv 
over MPLS, can be found in [MPLS-DS]. 
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In another approach, the ATM Forum has a requirement to indicate 
desired IP QOS treatments in ATM signaling, so that ATM switches can 
be just as supportive of the desired service as are IP forwarders. 
To do so the Forum is defining a new VC call setup information 
element is which will carry PHB identification codes (although will 
be generalized to do more if needed). 


2. Encoding 
PHBs and sets of PHBs are encoded in an unsigned 16 bit binary field. 
The 16 bit field is arranged as follows: 
Case 1: PHBs defined by standards action, as per [RFC 2474]. 


The encoding for a single PHB is the recommended DSCP value for that 
PHB, left-justified in the 16 bit field, with bits 6 through 15 set 
to zero. Note that the recommended DSCP value MUST be used, even if 
the network in question has chosen a different mapping. 


The encoding for a set of PHBs is the numerically smallest of the set 
of encodings for the various PHBs in the set, with bit 14 set to 1. 
(Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 
bit 14 set to 1.) 
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Case 2: PHBs not defined by standards action, i.e. experimental or 
local use PHBs as allowed by [RFC 2474]. In this case an arbitrary 12 
bit PHB identification code, assigned by the IANA, is placed left- 
justified in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero 
for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 
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Bits 12 and 13 are reserved either for expansion of the PHB 
identification code, or for other use, at some point in the future. 
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3. IANA Considerations 


IANA is requested to create a new assignment registry for "Per-Hop 
Behavior Identification Codes", initially allowing values in the 
range 0 to 4095 decimal. 


Assignment of values in this field require: 


-the identity of the assignee 

-a brief description of the new PHB, with enough detail to 
distinguish it from existing standardized and non-standardized 
PHBs. In the case of a set of PHBs, this description should cover 
all PHBs in the set. 

-a reference to a stable document describing the PHB in detail. 


During the first year of existence of this registry, IANA is 
requested to refer all requests to the IETF diffserv WG for review. 
Subsequently, requests should be reviewed by the IETF Transport Area 
Directors or by an expert that they designate. 


If the number of assignments begins to approach 4096, the Transport 
Area Directors should be alerted. 


4. Security Considerations 


This encoding in itself raises no security issues. However, users of 
this encoding should consider that modifying a PHB identification 
code may constitute theft or denial of service, so protocols using 
this encoding must be adequately protected. 
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Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF's procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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